Ethernet originated based on the idea of peers on a network sending messages in what was essentially a common wire or channel. Each peer has a globally unique key, known as the Media Access Control (MAC) address to ensure that all systems in an Ethernet have distinct addresses. Most modern Ethernet installations use Ethernet switches (also referred to as “bridges”) to implement an Ethernet “cloud” or “island” that provides connectivity to the attached devices. The switch functions as an intelligent data traffic forwarder in which frames are sent to ports where the destination device is attached. Examples of network switches for use in Ethernet network environments are found in U.S. Pat. Nos. 6,850,542, 6,813,268 and 6,850,521.
The IEEE 802.1Q specification defines a standard for Virtual Local Area Network (VLAN). Broadcast and multicast frames are constrained by VLAN boundaries such that only devices whose ports are members of the same VLAN see those frames. Since 802.1Q VLANS typically span many bridges across area common network, identification of VLANs is achieved by inserting a tag into the Ethernet frame. For example, according to the existing standard, a 12-bit tag that uniquely identifies a VLAN may be inserted into an Ethernet frame. This VLAN tag may be used to specify the broadcast domain and to identify the customer associated with a particular VLAN. The customer identifier is commonly referred to as the service instance domain since it identifies the service provided for a particular customer. In a service provider (SP) metro Ethernet network, the broadcast domain constrains the scope of traffic among network devices such that data packets are not multicast to all devices connected to the network. A system and method for efficiently distributing multicast messages within computer networks configured to have one or more VLAN domains is disclosed in U.S. Pat. No. 6,839,348.
The concept of a broadcast and a service instance domains is illustrated in FIG. 1, which shows a SP Metro Ethernet network 10 that includes a plurality of interconnected switches. Three provider edge (PE) devices located on the periphery of network 10 connect with two different customers, respectively represented by customer edge (CE) devices labeled CE1 and CE2. The broadcast domain (i.e., CE1) is shown by the bold, heavy line, which defines the particular switches and the path or span through the switches for traffic sent among the various customer sites. The service instance defines the particular customer associated with a given data packet, e.g., the customer of the CE1 sites as distinguished from the customer associated with devices CE2. Note that in the example of FIG. 1, both customers use the same broadcast domain. Traffic associated with a particular customer is uniquely identified by the service instance tag identifier.
FIG. 2 shows two data packet formats commonly used for sending frames over a Metro Ethernet network. Data packet format 11 complies with the IEEE 802.1Q specification and includes a customer MAC address field followed by a 12-bit VLAN tag that is used to specify both the broadcast domain and service instance. The customer's data payload is shown beneath the VLAN tag. (The uppermost portion of the data packet is also frequently referred to as the “outermost” portion, with the lowermost being synonymously referred to as the “innermost” portion.) The 12-bit VLAN tag field means that the IEEE 802.1 Q standard can support a combined total of up to 4,094 broadcast domains and service instance domains. For instance, the IEEE 802.1Q standard can support 4,094 broadcast domains, each corresponding to a single service instance domain or a single broadcast domain with 4,094 service instance domains. By way of further example, U.S. Pat. No. 6,430,621 teaches a method and apparatus that provides for grouping nodes in multiple VLANs using port-based VLAN grouping using IEEE 802.1Q based frame tagging.
Data packet format 12 corresponds to the proposed IEEE 802.1ad specification that supports so-called “Q-in-Q” encapsulation, or tag stacking mechanism. According to this draft standard, each data packet includes an upper (i.e., outer) 12-bit tag that designates one of up to 4,094 broadcast domains (or VLANs), and a lower (i.e., inner) tag that identifies one of up to 4,094 service instances. The proposed IEEE 802.1 ad standard thus alleviates some of the capacity limitations inherent in the IEEE 802.1Q standard by permitting each broadcast domain (each VLAN) to include up to 4,094 service instances. However, although the 802.1 ad draft standard is capable of satisfying many multipoint applications, it remains inadequate for point-to-point applications where a single device can multiplex/de-multiplex tens of thousands or hundreds of thousands of service instances within a single broadcast domain. Furthermore, the number of broadcast domains in Metro Area Network (MAN)/WAN applications can easily exceed the 4K limit. In addition, there are certain applications that require the end-user MAC addresses and/or the end-user's Frame Check Sum (FCS) to be tunneled through the MAN/WAN Ethernet network, a feature which is unsupported by the 802.1ad proposal.
Nortel Networks Corporation has proposed an approach known as “MAC-in-MAC” that attempts to solve the drawbacks inherent in the prior art. The Nortel proposal, however, is based on a flat VLAN domain (i.e., no VLAN tag stacking) and has a number of disadvantages. First, the MAC-in-MAC approach does not differentiate between broadcast domains and service instance domains; therefore, if the number of service instances is substantially larger than the required number of broadcast domains, the network nodes (i.e., switches, bridges, routers, etc.) will be burdened with supporting as many broadcast domains as there are service instances. Since more hardware/software intensive resources are needed to support a broadcast domain than a service instance, bandwidth suffers and network costs increase. Additionally, the MAC-in-MAC approach lacks interoperability with 802.1 ad bridges; lacks a feasible implementation capable of supporting millions of broadcast domains; and requires that all bridges within the network have the MAC-in-MAC capability, not just the edge bridges.
By way of further background, U.S. Pat. No. 6,789,121 discloses a method of providing a Virtual Private Network (VPN) service through a shared network infrastructure comprising interconnected PE devices having CE interfaces. Some of the CE interfaces are allocated to a VPN supporting a plurality of VLANs and are arranged for exchanging traffic data units with respective CE devices, each traffic data unit including a VLAN identifier. A virtual connection (VC) in the shared network infrastructure is directly derived from a known VPN identifier and a VLAN identifier known or discovered by a PE device. U.S. Pat. No. 6,484,209 teaches a system configured to forward multicast data based upon a first set of correlation data, wherein a first set of correlation data maps multicast group identifiers to ports that are members of the corresponding multicast groups. The switch core includes a second set of correlation data which maps multicast group identifiers to I/O cards that include member ports.
Thus, there is a need for alternative methods and apparatus that would accommodate the ever expanding number of broadcast domains and service instances of MAN/WAN Ethernet Networks while overcoming the shortcomings of past approaches.